Centralized data repositories are increasingly being used to store critical enterprise-wide meta-data, such as user information, services information, and organizational information. Such centralized data repositories provide many advantages over locally maintained repositories, allowing organizations to provide more efficient and secure methods to maintain the enterprise-wide meta-data.
A common approach to implement the central data repository is to use the Lightweight Directory Access Protocol (“LDAP”), which is a directory protocol that was originally developed as a front end to access directory systems organized under the X.500 standard for open electronic directories (which was originally promulgated by the Comite Consultatif International de telephone et Telegraphe “CCITT” in 1988). Standalone LDAP server implementations are now commonly available to store and maintain numerous types of system and enterprise meta-data. LDAP directory systems are normally organized in a structure having entries (i.e., objects) organized in the form of a tree, which is referred to as a directory information tree (“DIT”). A unique name or ID (which is commonly called a “distinguished name” or “DN”) identifies each LDAP entry in the DIT. An LDAP entry is a collection of one or more entry attributes. If structured properly, a DIT represents an explicit hierarchy.
FIG. 1 illustrates an example computing architecture having a centralized LDAP repository/directory 110 that includes system metadata. A LDAP repository 110 defines a storage model to hierarchically store data and a query protocol to access it. A number of remote nodes 112 and 116 are configured to access the data 102 in the central LDAP repository 110. The term “node” is used herein to represent any type of entity that may need to access the system meta-data, such as a server, standalone workstation, application, or instance of an application, or even smaller granularities of entities such as processes or threads.
Each of the nodes 112 and 116 require some sort of a mechanism to access the information 102 within LDAP directory 110. One approach is to maintain a local copy 120 of the required information 102 from the LDAP directory 110 in a local data repository 118, with the local copy 120 stored in an application specific local schema. In this approach, an application 114 that needs to access the system metadata would simply issue a SQL query against the local data repository 118 to access the local copy 120 of the data (assuming that the local copy 120 is in a relational database schema). Synchronization, e.g., using meta-directories, is used to maintain the correspondence between data in the local repository 118 and the central data repository 110. A problem with this approach is that such synchronization requires manual activities at the deployment site and requires computational resources from the directory integration platform. These problems may cause unacceptable levels of inefficiencies to perform the process of synchronizing the system metadata.
Another approach is to recode the application 128 at the node 116 to include a customized LDAP interface 126 to directly access the data 102 in LDAP directory 110. For example, if the application 128 is a database application, the SQL layer of the application may need to be rewritten with specialized APIs to include the LDAP interface 126. The problem with this approach is that it requires the developer of the application 128 to write and maintain custom code for the LDAP interface 126, which can be a time-consuming and in many cases, a non-trivial task because the inherent search characteristics of the LDAP interface is significantly different from the query and analysis nature of the SQL language.
Embodiments of the present invention provide an improved method, mechanism, and system for referencing and accessing centrally managed information. According to some embodiments, the invention provides transparency to the centrally managed data by introducing a mapping system between locally expected data and the central data repository. This allows, for example, local relational database systems to transparently access information from a central LDAP directory. This combines the benefits of the direct API access with that of synchronization in one simple and easy to use interface for developers.
Further details of aspects, objects, and advantages of the invention are described below in the detailed description, drawings, and claims. Both the foregoing general description and the following detailed description are exemplary and explanatory, and are not intended to be limiting as to the scope of the invention.